기술부채, 피할 수 없다. 그냥 버텨. | 매거진에 참여하세요

나는 오늘도 개발하면서, 기술부채 해결하면서 앞으로 나아가고 있다.

실제 예로, 덕지덕지 되어있는 css를 거둬내어, 컴포넌트에 종속적인 scss로 바꾸고,

중복 개발되어있는 컴포넌트를 하나로 합치고, 통일되어있지 않은 변수를 통일하는 등을 넘어서

리액트의 구조나 기술에 대해서 제대로 알지 못한상태로 개발했던

많은 비효율성 구조 등을 걷어내고, 서버를 효율화하고 하는 작업등을 병행하면서 말이다.

과거의 나를 탓하자! 기술부채란 무엇인가?

기술부채(Technical Debt)는 소프트웨어 개발 과정에서 장기적인 최선책보다는 당장의 실행 가능성과 속도를 우선해 생기는 기술적 비용이다.

쉽게 말해 "일단 돌아가게 만들고, 나중에 제대로 고치자"는 선택이다.

이는 마치 당장의 자금 흐름을 위해 빚을 내는 것과 비슷하다.

처음엔 부담이 적지만 시간이 지나면 그 이자는 점점 커진다.

유지보수가 어려워지고, 새로운 기능 추가에 제약이 생기며, 조직 전체의 기술 민첩성이 저하된다.

하지만 중요한 건, 기술부채가 항상 잘못된 결정이나 개발자의 게으름에서 비롯되는 게 아니라는 점이다.

시장 반응을 빠르게 보기 위한 MVP 개발, 빠듯한 마감일, 아직 불확실한 요구사항 속에서 유연하게 대처하려는 전략적 선택이기도 하다.

기술부채는 때로 살아남기 위해 지불하는 ‘생존 비용’이며, 그것을 감수할 용기가 있어야 기회를 얻을 수 있다.

기술부채를 피할 수 없는 현실

기술부채를 완전히 피할 수 있는 이상적인 상황은 존재하지 않는다. 이 세상에 완벽한 코드나 설계는 없다.

실수를 줄이기 위해 노력할 수 있지만, 결국 개발은 항상 불확실성과 맞닿아 있다.

당장의 요구 사항을 충족시키기 위해, 혹은 빠르게 결과를 내기 위해 적절한 타협을 해야 하는 순간들이 있다.

그럼에도 불구하고 중요한 건 이 부채가 쌓이지 않도록 지속적으로 관리하는 것이다.

"한 번의 타협이 두 번의 부채를 부른다"는 말을 마음에 새기고, 기술부채가 계속 쌓이지 않도록 해야 한다.

기술부채는 언제, 왜 발생하는가?

기술부채는 다양한 상황에서 발생한다.

가장 일반적인 경우는 비즈니스 일정이 촉박할 때다. 출시일은 정해져 있고, 팀 규모는 작으며,

고객의 피드백이 시급할 때 개발팀은 완벽한 설계보다는 빠른 결과를 선택할 수밖에 없다.

하지만 기술부채의 또 다른 중요한 발생 원인은 바로 기술 숙련도의 부족이다. 이는 두 가지 측면에서 나타난다.

첫째, 경험 부족으로 인한 설계 미스다.

초보 개발자 혹은 해당 도메인에 익숙하지 않은 개발자가 초기 구조를 잘못 설계하거나,

향후 확장성과 재사용성을 고려하지 못한 채 코드를 작성하면 시간이 지날수록 유지보수가 어려운 구조가 된다.

당시엔 최선이라 생각했지만, 시간이 지나고 나서야 비로소 ‘더 나은 방법이 있었다’는 걸 알게 되는 경우다.

둘째, 기술 트렌드나 도구에 대한 이해 부족이다.

새로운 프레임워크나 라이브러리, 클라우드 환경 등은 빠르게 발전하고 있지만 이를 제대로 이해하지 못한 상태에서 억지로 적용하면 예상치 못한 부채가 쌓인다.

예를 들어 React에서 상태관리를 잘못 이해하고 무분별하게 prop drilling을 하거나,

데이터베이스 인덱스 설정 없이 고비용 쿼리를 남발하는 것도 기술 숙련도 부족에서 비롯된 부채다.

그렇기에 기술부채는 단순히 '빚'이라기보다는 기술 성장 과정에서의 흔적이다.

경험이 쌓이고 역량이 향상됨에 따라, 과거의 코드가 미숙하게 느껴지고, 다시 고치고 싶은 충동이 드는 건 자연스러운 일이다.

오히려 기술부채는 '우리가 성장하고 있다'는 증거일 수도 있다.

만약 기술 숙련도 부족으로 인해서, 기술부채가 생기는 것이라면

이건 방법이 없다. 그냥 인내하고 가야 한다.

아니면, 나보다 더 잘하는 애를 뽑았어야지.

나중에 우리가 잘되면 , 내 코드를 누군가 잘하는 사람이 다시 짜줄것이라는 희망을 품고 견뎌내야 한다.

3. 모든 기술부채가 갚아야 할 대상은 아니다

기술부채가 생겼다고 해서 반드시 모두 갚아야 하는 건 아니다.

어떤 기술부채는 일시적이고, 어떤 건 전략적으로 무시해도 괜찮다.

예를 들어 단발성으로 운영될 프로모션 페이지나, 곧 기능이 대체될 예정인 모듈에 완벽한 구조를 적용하는 것은 낭비일 수 있다.

중요한 건 부채의 존재를 인지하고 있느냐이다. 어디에 어떤 부채가 있으며, 그것이 조직에 미치는 영향이 무엇인지 파악하고 있다면,

그것은 ‘위험한 채무’가 아닌 ‘통제 가능한 투자’다.

오히려 위험한 것은 기술부채의 존재조차 모른 채 쌓아만 가는 상황이다.

기술부채의 우선순위를 정하고, 리팩토링 계획을 세우며, 그것을 스프린트 내 작업 범위에 명확히 포함시키는 것. 이것이 기술부채를 관리하는 조직의 자세다.

4. 기술부채를 수용하는 조직문화 만들기

기술부채는 감추거나 부정해서는 해결되지 않는다.

기술팀이 이를 자유롭게 논의할 수 있는 분위기, 그리고 이를 해결할 수 있는 시간을 확보해주는 시스템이 있어야 한다.

대표적으로 ‘부채 청산 데이’나 ‘리팩토링 주간’ 같은 시간 확보가 있다.

또한 기술적 결정을 기록하고 공유하는 문화, 예컨대 ADR(Architecture Decision Record)을 남기는 습관은 향후 발생할 부채를 줄여주는 예방책이 된다.

중요한 건 개발자와 비개발자 간의 기술부채에 대한 인식 차이를 줄이는 일이다.

기술 리더는 부채의 존재를 경영진에게 '시간 낭비'가 아니라 '위험 관리'로 설명해야 한다.

"이 구조를 지금 리팩토링하지 않으면 3개월 뒤부터 신규 기능 개발이 지연될 수 있습니다"라는 언어로 바꾸면, 비즈니스 의사결정권자도 이해할 수 있다.

기술부채 관리의 핵심: 우선순위와 의사결정

기술부채를 관리하는 데 가장 중요한 것은 우선순위를 정하는 것이다.

모든 기술부채를 다 해결하려고 하면 시간과 리소스를 낭비할 수 있다.

대신, 현재 비즈니스 목표와 가장 관련이 깊은 부채부터 해결하는 것이 중요하다.

또한, 부채를 해결하는 데 필요한 자원을 확보하고, 이를 실행에 옮기기 위한 의사결정이 필요하다.

예를 들어, 한정된 시간 내에 리팩토링을 하거나 새로운 기능을 추가해야 할 때, 팀원과 함께 협의하여 가장 중요한 작업을 먼저 진행하는 방식이다.

이런 방식으로 문제를 해결해 나가면, 작은 성공들이 쌓여 나가면서 전체적인 기술부채를 효과적으로 관리할 수 있다.

5. 기술부채는 성장의 증거다

기술부채는 어떤 면에서 조직이 빠르게 성장하고 있다는 증거다. 정체된 서비스에는 기술부채조차 없다.

변화가 있고 실험이 있고 고객 피드백이 있는 곳에서만 부채는 생긴다.

또한, 과거에는 몰라서 저지른 실수였지만, 지금은 명확히 문제를 인식할 수 있다는 것은 개발자의 역량이 성장했다는 뜻이다.

기술부채는 개발자의 잘못이라기보다, 그 당시의 최선이었고 현재의 시야로 다시 바라보며 개선해나가는 성장의 연속이다.

기술부채를 해결하는 과정에서의 도전과 성취

기술부채를 해결하는 과정은 단순히 코드를 고치는 일이 아니다.

때로는 시스템을 근본적으로 이해하고, 처음부터 다시 설계하는 것과 비슷하다.

하지만 이 과정에서 얻는 것은 단지 코드의 품질 향상에 그치지 않는다.

기술부채를 해결하는 과정에서 팀의 협업 능력도 한층 강화된다.

서로의 생각을 공유하고, 문제를 해결하는 과정에서 얻는 경험은 개발자로서 성장하는 데 중요한 밑거름이 된다.

물론 중간중간 좌절과 어려움도 있지만, 그 어려움을 넘기면 이전보다 더 나은 시스템과 코드, 그리고 더 성숙한 팀을 만들어낼 수 있다는 점에서 보람을 느낄 수 있다.

기술부채를 넘어선 혁신적인 접근

기술부채를 해결하는 것만이 전부는 아니다. 실제로 기술부채를 해결하는 과정에서 새로운 기술이나 혁신적인 접근을 도입할 수 있는 기회를 발견하기도 한다.

예를 들어, 기존의 모놀리식 구조에서 마이크로서비스로 전환하거나, 수동으로 처리하던 배포 과정을 자동화하는 등의 방식이다.

기술부채를 해결하는 일은 때로는 그 자체로 혁신을 일으킬 수 있는 기회가 된다.

이전에 해결되지 않았던 문제들을 새로운 시각에서 바라보고, 이를 해결하는 과정에서 비즈니스나 기술 측면에서 혁신을 일으킬 수 있다.

기술부채는 죄가 아니다, 현실이고 성장의 일부다

기술부채를 무조건 나쁘게만 보는 시각은 현실을 왜곡하고, 개발자들을 위축시킨다.

기술부채는 제품이 진화하면서 불가피하게 발생하는 결과이며, 때로는 전략적인 판단의 결과다.

숙련도가 부족해서 생긴 부채도 마찬가지다. 그건 잘못이 아니라, 성장의 여정이다.

기술부채를 피할 수 없다면, 최소한 제대로 기록하고, 의도하고, 관리하자.

그러면 그것은 더 이상 ‘부채’가 아니라 ‘투자’가 된다.